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INTRODUCTION 

It  is  becoming  daily  more  common  to  hear  and  read  about  computer 
and  data  related  security  problems.   Nowadays  it  is  very  common  to  find 
references  to  it  in  sociology  magazines  [2,20],  newspapers  [2,21],  banking 
media  [2,22],  congressional  papers  [2,12]  and  even  in  nonclosely  related 
magazines  such  as  Playboy  [2,25], 

The  term  data  security,  as  defined  by  James  Martin  [17]>  is  the 
"protection  of  data  against  accidental  or  intentional  disclosure  to 
unauthorized  persons,  or  unauthorized  modification  or  destruction." 

As  is  easily  seen,  there  are  many  levels  of  security.  As  shown 
in  Figure  1  those  different  levels  of  security  could  be  broken  into  k 
classes,  as  follows. 

A.   The  Legal  and  Societal  Environment 

This  refers  to  the  environment  that  must  surround  the  concern  for 
security.   To  be  able  to  speak  about  security  as  a  positive  goal,  it  must 
first  be  seen  as  a  desirable  thing  within  the  society.   It  is  not  worth 
it  to  speak  about  security  if  the  society  just  doesn't  need  it. 

Once  society's  needs  for  security  have  been  established,  some 
legislation  is  required,  such  as,  for  example,  to  formalize  what  we 
mean  by  a  robbery  where  no  actual  physical  object  is  stolen,  i.e.,  data 
or  information  robbery. 
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B.   The  Administrative  Controls 

Without  an  administrative  framework  there  is  no  sense  in  speaking 
about  security.   This  class  of  security  is  really  the  one  that  combines 
the  other  three  classes  into  a  comprehensive  system. 

We  should,  start  by  admitting  that  absolute  security  is  unattainable. 
Many  parameters  involved,  are  not  just  administratively  uncontrollable, 
but  not  even  humanly  controllable,  such  as  fire,  earthquake,  hardware 
failure,  etc.   The  basic  goal  must  then  be  to  minimize  the  vulnerability 
to  such  hazards  rather  than  eliminate  them. 

For  each  type  of  exposure  to  a  security  hazard  we  should  consider 
the  "three  level  attack"  proposed  by  James  Martin  [17]  by: 

1.  minimizing  the  probability  of  it  happening  at  all, 

2.  minimizing  the  damage  if  it  does  happen,  and 

3.  furnishing  a  method  of  recovering  from  the  damage. 

Once  we  accept  the  fact  that  absolute  security  is  impossible,  some  high 
level  administrative  decisions  must  be  made,  such  as:  How  much  security 
should  one  add  to  a  system?  Where  is  the  breakpoint  of  a  cost/benefit 
evaluation  of  cost  vs.  security?  How  can  we  evaluate  the  benefit  of 
a  secure  system? 

Once  we  answer  the  above  questions  we  find  ourselves  facing 
another  set  of  problems,  the  human-related  administrative  controls,  such 
as :  How  should  we  select  our  personnel?  What  types  of  auditing  are 
required?  How  should  the  work  teams  be  organized? 

Many  articles  have  been  written  dealing  with  these  subjects,  but 
most  of  them  are  concerned  with  pointing  out  the  problems  to 
management  [1,2,5,17,18,19,23]. 
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C.  Physical  Security 

This  is  probably  the  best  known  type  of  security,  basically 
because  we  refer  to  this  class  of  security  when  we  are  dealing  with  banks, 
stores,  etc.   The  concepts  of  guards,  alarms,  locks,  vaults,  fire 
protection,  etc.  are  common  to  all  of  them. 

When  we  speak  about  physical  security  in  data  systems  we  must 
include  such  sophisticated  techniques  as  cryptography,  wire-tapping,  and 
electromagnetic  radiation,  mainly  because  the  object  to  be  secured  is 
not  as  tangible  as,  e.g.,  money,  in  the  bank  case.   Again  the  nonphysical 
characteristic  of  the  data  plays  an  important  role. 

Since  physical  security  is  so  important  in  so  many  other  fields, 
there  is  a  large  body  of  good  work  done  already  [17]. 

D.  Security  and  Accuracy  Controls  Built  Into 
Data  Processing  Systems 

This  is  the  type  of  security  that  is  closest  to  the  computer  in 
the  sense  that  it  is  contained  within  the  computer.   Once  a  user  penetrates 
the  other  classes  of  security,  this  is  the  only  one  left  to  stop  him. 

From  the  various  active  infiltrations  [7]  that  a  user  could 
exercise  to  violate  security,  a  few  of  them  could  only  be  detected  by 
security  measures  in  this  area,  as  for  example:  browsing,  trap  doors, 
and  core  dumps.   Browsing  is  defined  as  the  use  of  legitimate  access  to 
the  system  to  obtain  unauthorized  information,  also  known  as  the 
"Trojan  horse"  approach.   Trap  doors  are  hardware  or  software  deficiencies 
that  assist  the  infiltrator  to  obtain  information  having  once  gained 
access  to  the  system.   Core  dumps  can  allow  the  current  program  to  read 
data  from  the  previous  program  or  concurrent  programs  if  either  memory 
has  not  been  zeroed  between  jobs  or  memory  protection  permits  reads. 


Even  though  it  is  almost  impossible  to  give  priorities  to  the 
above  classes,  or  to  speak  about  a  particular  class,  as  an  independent 
entity,  without  losing  generality,  I  will  discuss  mainly  the  fourth  class 
of  security.   The  main  reason  for  restricting  our  study  to  the  fourth 
class  is  that  that  is  the  area  where  the  experience  of  the  computer 
scientist,  as  an  attacker  or  defender,  comes  into  play.   In  the  other 
classes  of  security  the  role  of  a  computer  scientist  remains  advisory  at 
best,  and  decisions  are  really  made  by  a  congressman  or  administrator. 

On  the  other  hand,  not  much  is  known,  or  at  least  published  about 
this  area,  probably  because  it  is  so  new.   In  fact,  there  are  differences 
of  opinion  about  the  definition  of  the  problem,  an  acceptable  way  to  solve 
it,  and  even  in  what  terminology  to  use. 

It  will  then  be  the  purpose  of  this  paper  to  describe  the 
state-of-the-art  that  I  have  found  in  the  literature  about  security 
built  into  data  processing  systems. 


I.   THE  STATE  OF  THE  ART 

Searching  through  the  literature  I  have  found  3  categories  of  papers 
related  to  security  inside  data  processing  systems.   I  will  call  them: 
explanation,  sales,  and  comprehensive  systems. 

The  category  of  explanation  contains  those  papers  [1,  U,  5,  6, 7>  1^,18, 
19,23]  whose  main  concern  is  to  expose  the  reader  to  the  security  problems. 
Most  of  them  are  directed  to  management  and  the  exposition  of  the  problem 
is  their  only  concern  with  very  little  discussion  of  solutions.   Others, 
after  a  brief  exposition,  attack  one  of  the  problems  in  a  stronger 
fashion  (as  for  example:  the  problem  of  confidentiality  of  individual 
records  in  data  storage  and  retrieval  for  statistical  purposes  [1^]  or 
ways  of  encoding  data  [7]).   None  of  them  tries  to  give  a  comprehensive 
solution  to  the  security  problem  and  we  will  not  discuss  them  further. 

The  category  of  sales  includes  those  papers  [3]  whose  main 
intention  is  to  describe  a  working  comprehensive  system,  but  their 
description  is  so  vague  and  short  that  it  sounds  basically  like  a 
commercial  where  everything  works  nicely.   For  example,  the  1  1/2  page 
description  of  the  RUSH  time-sharing  system  [3]  includes  a  sentence 
"This  protection  is  now  available  in  RUSH,  and  guarantees  full  security 
to  time-sharing  users,  program,  data,  and  program/data  files. "  which  is 
just  too  nice  to  be  true. 
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Obviously,  these  papers  too  won't  be  included  in  the  following 
discussion  even  though  they  refer  to  a  comprehensive  system. 

The  third  and  most  important  category,  for  our  purposes,  is  the 
"comprehensive  systems"  category.  As  will  be  explained  later  there  does 
not  exist  such  a  thing  as  a  comprehensive  security  system,  but  the  systems 
described  next  are  really  trying  to  approach  it,  and  hence  the  name. 

Within  this  category  I  will  describe  the  following  papers: 

1.  multi-dimensional  security  program  for  a  generalized 
information  retrieval  system  [8], 

2.  the  formulary  model  for  flexible  privacy  and 
access  controls  [15]  > 

3.  on  the  implementation  of  security  measures  in 
information  systems  [10]. 

h.      security  controls  in  the  ADEPT-50  time-sharing 
system  [2k], 

5.   protection  in  an  information  processing  utility  [13]. 

The  approach  that  I  will  take  will  be  first  of  all  to  give  a  brief 
description  of  each  one  of  the  5  systems  (Chapter  II),  then  to  try  to 
evaluate  each  one  (Chapter  III),  and  finally  to  give  a  short  summary 
(Chapter  IV)  of  the  state-of-the-art  as  pointed  out  by  the  systems 
discussed. 


II.   THE  SYSTEMS 

A.   Multi-dimensional  Security  Program  for  a  Generalized 
Information  Retrieval  System 

The  authors  have  developed  a  generalized  information  retrieval 
system  (GIRS  [8] )  at  the  University  of  Western  Ontario,  in  London,  Ontario, 
Canada.   The  system  was  programmed  in  FORTRAN  ("for  maximal  portability 
among  computer  systems")  on  a  PDP-10  computer. 

The  GIRS's  security  provisions  include  three  levels  of  security: 

1.  level  1  protection  -  to  specify  which  of  the  ten 
available  processing  functions  (CREATE,  DISPLAY, 
SEARCH,  etc.)  can  the  user  exercise. 

2.  level  2  protection  -  will  give  information  about 
which  portions  of  records  are  available  to  a 
particular  user. 

3.  level  3  protection  -  will  establish  which  records 
within  a  file  can  be  seen  by  that  user. 

The  data  structure  of  GIRS  is  a  forest,  with  as  many  trees  as 
data  bases  are  required. 

Each  tree  (data  base)  is  divided  into  two  parts:  header  and  data. 
The  data  is  divided  into  records  (up  to  99*998).   Each  record  is  further 
divided  into  items  (up  to  10)  and  each  item  into  lines  (up  to  10).   Each 
line  contains  72  characters  and  could  be  subdivided  into  elements  by  the 


use  of  delimiters.   Thus,  each  line  could  be  described  by  a  unique  7-digit 
number  (5  for  record,  1  for  item,  1  for  line). 

The  header  contains  information  about  passwords,  protection  keys, 
details  about  items  (number  of  lines,  protection,  elements,  and  item's 
name)  and  index  to  data  records  (this  index  is  set  up  to  reference  every 
(l60n)th  record  where  n  is  a  user  parameter). 

There  is  one  further  restriction  on  this  structure — all  records 
in  a  file  must  have  the  same  number  of  items  and  they  must  be  present  in 
the  same  order  in  all  records. 

Protection  1  is  obtained  by  setting  one  bit  in  the  appropriate 
place  of  the  header  for  each  function  that  each  user  can  perform. 

Protection  2  is  obtained  in  a  similar  fashion,  setting  a  bit  for 
each  of  the  items  available. 

The  level  3  protection  is  obtained  by  associating  a  security 
clearance  number  to  each  user,  as  well  as  to  each  line  (from  the  80  columns 
in  a  card  image  only  72  are  used  for  actual  data,  the  other  8  are  used 
for  identification  and  level  3  security  number).  A  user  can  then  see 
all  records  with  security  clearance  number  less  than  or  equal  to  his  own 
clearance  number. 

An  optional  lock  system  is  also  available  for  additional  level  3 
protection,  i.e.,  some  records  can  be  completely  locked  for  given  users. 
This  is  obtained  by  associating  with  each  user  one  or  two  sets  of 
modulo-remainder  (M-R)  pairs.   The  user  will  only  get  access  to  those 
records  whose  remainder  modulo  M  is  R,  e.g.,  M  =  2,  R  =  0  gives  access  to 
all  even  number  records. 
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The  authors  conclude  by  claiming  that  GIRS  "provides  a  test  bed 
for  continuing  experimentation  with  security  provisions  for  multiple -ace ess 
computer  communications  systems.   By  such  experimentation,  it  is  anticipated 
that  the  optimal  trade  offs  between  security  and  economy  can  be  determined 
for  a  wide  range  of  information  retrieval  applications. " 

B.   The  Formulary  Model  for  Flexible  Privacy  and. 
Access  Controls 

The  present  paper  [15]  is  a  condensation  of  the  author's  Ph.D.  thesis; 
the  main  motivation  being  to  implement  a  security  system  for  the  student 
health  system  at  Stanford  University. 

His  main  goal  was  to  create  a  model  independent  of  both  machine 
and  data  base  which  could  help  answer  questions  such  as  "How  much  does 
technique  X  cost? " 

In  the  "formulary"  method  the  decision  to  grant  or  deny  access  is 
made  at  data  access  time  by  a  program,  thus  giving  as  much  flexibility 
as  possible. 

For  any  particular  interpretation,  the  installation  must  supply 
the  following  procedures : 

1.  at  least  one  TALK  procedure, 

2.  coding  for  the  ACCESS  algorithm, 

3.  primitive  operations:   FETCH  and  STORE, 
h.      at  least  one  formulary,  consisting  of: 

-  CONTROL  procedure 

-  VIRTUAL  procedure 

-  SCRAMBLE  procedure  (may  be  null) 

-  UNSCRAMBLE  procedure  (may  be  null) 
5.   a  FORMULARY  BUILDER  procedure. 
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Each  of.  these  procedures  has  a  strictly  delimited  function,  described 
later. 

The  basic  idea  behind  the  formulary  method  is  that  a  user,  a 
terminal,  and  a  previously  built  formulary  must  be  linked  or  attached 
together,  in  order  for  a  user  to  perform  any  data  manipulation.  At  run 
time  this  information  (user,  terminal  and  formulary),  is  kept  in  the 
User  Control  Block  (UCB)  in  central  core.   Figure  2  will  help  to  make 
clear  the  user/data-base  interface. 

The  TALK  procedure  is  in  charge  of  the  interactive  conversation 
between  system  and  user  or  user  program.   TALK  should  get  from  the  user 
or  his  program:  datum  description  in  a  user-oriented  language,  operation 
to  perform,  identification,  and  other  information  about  user  and  terminal. 
TALK  then  calls  ACCESS  passing  three  parameters:  datum  description  in  an 
internal  fashion,  operation  desired  and  proper  user  and  terminal 
identification.   There  is  no  limit  to  the  number  of  TALK  procedures 
which  can  exist,  and  it  is  a  user  decision  which  TALK  procedure  to  call. 

The  ACCESS  procedure  uses  the  UCB  and  the  information  given  by 
TALK  to  try  to  honor  the  users  request.   ACCESS  will  first  call  CONTROL, 
passing  the  internal  name  of  the  datum  and  the  desired  operation.   CONTROL 
decides  whether  or  not  to  allow  the  request—it  could  interact  with  the 
user  before  arriving  at  a  decision,  and  thus  the  arrow  between  formulary 
and  user  in  Figure  2.   CONTROL  will  basically  return  a  yes  signal  or  a 
no  signal  including  the  reason  why  the  operation  is  denied. 

If  CONTROL  says  yes,  VIRTUAL  is  called.   VIRTUAL  should  return 
the  resulting  virtual  address  for  the  requesting  datum. 
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Figure  2.   User/data  Base  Interface 
in  the  Formulary  Model 
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At  this  moment  ACCESS  performs  the  required  operation  and,  if 
necessary,  calls  SCRAMBLE  or  UNSCRAMBLE  which  encrypts  or  decrypts  data. 

FETCH  and  STORE  are  the  actual  procedures  which  read  or  write 
from/into  the  data-base. 

The  last  procedure,  FOPMULARYBUILDER,  interacts  with  the  system 
programmer  to  make  the  appropriate  attachments  of  formularies  to  user- 
terminal  combinations. 

The  model  includes  provisions  for  concurrent  requests,  obtained 
by  including  the  FETCHLOCK,  STORELOCK,  UNLOCKFETCH,  and  UNLOCKSTORE 
operations. 

There  also  exists  a  default  formulary  which  should  be  called 
whenever  an  unspecified  user-terminal  combination  is  found  for  the  first 
time;  this  default  formulary  should  either  attach  a  formulary  to  the  new 
combination  or  deny  access. 

The  paper  goes  into  great  detail  in  the  explanation  of  the 
procedures,  including  the  presentation  of  an  ALGOL  algorithm  for  the 
ACCESS  procedure  and  a  more  precise  definition  of  the  parameters  for  each 
procedure. 

Using  the  formulary  method,  an  experiment  was  run  on  the  IBM  360/91 
computer  at  the  SLAC  facility  at  Stanford.   The  experiment  was  designed 
to  measure  overhead  obtained  by  using  encoding,  and  early  results  showed 
that  they  seem  relatively  small. 

C   On  the  Implementation  of  Security  Measures  in 
Information  Systems 

This  paper  [10]  should  be  read  in  conjunction  with  a  closely  related 

paper  by  the  same  authors:   "Selective  Security  Capabilities  in  ASAP"  [9]. 

The  work  was  done  at  Cornell  University. 
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The  article  starts  by  defining  what  they  mean  by  information 
security  ("procedures  to  ensure  that  privacy  decisions  are  in  fact 
enforceable  and  enforced")  and  the  authors'  general  approach  to  the 
problem. 

They  list  the  requirements  that  information  systems  have  for 
selective  security  and  state  that  to  the  best  of  their  knowledge,  no 
security  system  exists  with  such  provisions. 

Conceptually,,  in  their  model,  the  privacy  decisions  for  a  particular 
data  bank  may  be  recorded  in  a  "security  matrix. "  The  columns  of  this 
matrix  correspond  to  particular  data  structures  in  the  system- -not 
necessarily  disjoint—and  the  rows  of  the  matrix  correspond  to  potential 
users  of  the  system.   Each  element  in  the  matrix,  d. .,  is  a  decision  rule 
embodying  a  specific  privacy  decision,  specifying  the  conditions  under 
which  user  i  is  entitled  to  access  to  the  data  structure  j  and  the  actions 
that  i  is  permitted  to  perform  upon  j. 

Even  though  the  above  model  could  work,  it  is,  in  general,  a 
prohibitively  large  solution.  A  practical  implementation  of  the  security 
matrix  is  established  by  the  "careful  analysis  of  when  and  how  the  matrix 
should  be  interrogated  and  its  specification  employed. " 

Their  analysis  shows  that  the  security  matrix  is,  in  general,  very 
sparse — most  of  the  entries  are  denials  of  access — and  that  only  a  very 
small  part  of  the  security  matrix  is  relevant  at  a  particular  moment. 
Thus,  the  appropriate  solution  could  be  to  have  a  very  small  controlling 
submatrix  which  could  be  identified  and  remain  in  control  for  a  significant 
amount  of  processing  time. 
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All  the  previous  ideas  are  put  together  into  the  authors' 
"functional  model  of  a  security  matrix"  described  next. 

The  functional  model  includes  the  security  matrix  and  four 

functions:  F  and  S  ,  the  translation-time  fetch  and  store  correspondingly, 

and  F  and  S  ,  the  run-time  fetch  and  store  functions, 
r      r 

The  four  functions  have  two  arguments,  user  and  datum  name,  thus, 
reflecting  a  particular  element  of  the  security  matrix. 

At  translation  time  F  is  called  each  time  that  a  fetch  is 
referenced  in  the  source  code.   F  then  takes  one  of  the  following  actions: 

1.  If  user  is  permitted  data  independent  fetch  to  the 
datum,  the  conventional  object  code  is  generated. 

2.  If  user  is  denied  any  kind  of  access  to  the  datum, 
the  translation  is  aborted  and  the  system  is  alerted 
to  perform  threat  monitoring. 

3.  If  user  has  a  data  dependent  request  to  access  the 

datum,  object  code  is  emitted  to  call  F  at  run-time. 

S,  and  S  are  handled  similarly, 
t      r 

Thus,  if  we  are  dealing  with  data- independent  security  checking  then 

F,  and  S,  represent  a  very  slight  overhead  at  translation- time  and  none 

at  execution- time.   The  overhead  work  of  the  functions  F  and  S  is  then 

r      r 

only  performed  at  run-time  when  it  cannot  be  done  at  translation-time. 

Except  for  minor  changes  this  model  is  actually  running  in  the 
ASAP  file  maintenance  system  [10]. 

After  the  feasibility  of  the  model  has  been  shown,  the  authors  go 
a  little  further  and  attack  the  problem  of  general  implementation  in 
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languages  such  as  PL/ I,  FORTRAN,  and  COBOL  and  operating  systems  such  as 
the  OS/360. 

This  extension  was  somewhat  expected,  since  their  model  works 
only  if  embedded  in  a  secure-translator  environment. 

After  they  point  out  the  inefficiency  of  any  implementation  that 
doesn't  distinguish  between  data  independent  and  dependent  decisions  and 
treats  them  all  as  run-time  decisions.   They  consider  alternative  ways 
of  implementing  F,  and  S+ :  toy  modifying  the  standard  compiler  or  by 
interposing  a  preprocessor  in  front  of  the  standard  compiler. 

Even  though  the  first  is  more  efficient,  they  recommend  the 
second  since  no  deep  modifications  in  the  interior  of  sophisticated 
compilers  should  be  permitted,  and  maintenance  is  much  more  difficult 
if  local  patches  are  made. 

The  preprocessors  could  basically  be  the  same  compilers,  excluding 
the  code  generation  part,  which  means  that  the  syntactic  analysis  is  done 
twice.   But  this  could  "readily"  be  tolerated,  and  they  give  as  an 
example  a  preprocessor  for  PL/ I  based  on  Cornell's  PL/C  compiler  which 
can  scan  15,000  PL/ I  scource  statements  per  minute  on  a  360/65. 

With  either  a  preprocessor  or  a  modified  compiler  certain  serious 
problems  would  remain,  such  as  detection  of  invalid  indexes  in  arrays, 
improper  use  of  pointers  (in  PL/l),  etc.  which  could  only  be  controlled 
by  limiting  the  freedom  of  the  programmer  to  use  the  full  facilities  of 
the  source  language,  and/ or  generating  extra  code  (i.e.,  SUBSCRIPTRANGE 
enabled  in  PL/ I  for  invalid  index  detection)  and  thus,  overhead. 
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D.   Security  Controls  in  the  ADEPT- 50  Time -sharing  System 

The  ADEPT-50  time- sharing  system  was  implemented  by  C.  Weissman  [2k] 
on  an  IBM  360/5O  with  partial  support  by  the  Advanced  Research  Projects 
Agency  of  the  Department  of  Defense,  so  the  military  orientation  is  very 
obvious. 

Weissman' s  model,  slightly  different  from  the  actual  ADEPT 
implementation  explained  later,  is  very  straightforward.   He  establishes 
four  important  objects  of  security—users  (u),  terminals  (t),  jobs  (j)  and 
files  (f) — and  three  security  profiles- -Authority  (A),  Category  (C)  and 
Franchise  (F).   The  basic  problem  is  then  defining  how  the  matrix  of 
objects  by  profiles  should  be  filled  (a  k   by  3  matrix). 

Authority  is  related  to  government  and  military  classification 
(Top  Secret,  Secret,  etc. )  and  is  defined  as  a  set  (A)  of  hierarchically 
ordered  security  jurisdictions  (A  =  {a  <  a  <  ...  <  a  }). 

Category  refers  to  the  host  of  special  control  compartments 
(projects  or  access  by  project  and  area)  and  is  viewed  as  a  discrete  set 
of  specific  compartments,  c   (C  =  {c  ,  c  ,  ...  cV}). 

Franchise  is  a  security  jurisdiction  privileged  to  a  given  set  of 
users,  (F  =  (u|u  is  user] ). 

For  a  user,  u,  the  authority,  A  ,  and  category  C  ,  are  given 
constants;  for  completeness  the  Franchise  is  itself,   P  =  u. 

A  and  C,  ,  the  authority  and  category  for  a  given  terminal  t,  are 
also  given  constants.  F,  is  the  set  of  users  {u, )  authorized  to  use  that 
terminal. 

Jobs  are  initialized  by  users  through  some  terminal,  then  it 
seems  logical  to  define  A.  as  the  minimum  authority  of  user  and 
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terminal  (min  (A  ,  A ,  )),  and  the  category,  C.,  as  the  intersection  of 
11   t  j 

categories  (C .  =  C  0  C, ).   The  franchise.  F.,  is  a  collection  of  users  u. 
(in  the  actual  implementation  u.  =  u). 

We  Consider  two  cases:  new  files  and  files  that  already  exist. 
For  existing  files  the  authority  and  category,  A_  and  C  ,  are  given 
constants,  and  F„  is  a  list  of  users  with  access  to  that  file.   In  the 
case  of  new  files  a  new  concept  is  established,  the  history.   The  authority 
history  (Af )  is  just  the  maximum  authority  of  the  files  accessed  by  a  job. 
The  category  history  ((0  is  the  union  of  all  the  files  categories.   F 
remains  with  the  same  interpretation  as  above,  mainly  F_  =  u.  (in  the 
implementation  Ff  for  a  new  file  is  then  u). 

The  above  explanation  is  all  we  need  to  understand  the  model.  At 

log-in  time  to  the  system,  the  franchise  of  the  terminal  is  verified 

to  see  if  he  is  a  legal  user  for  the  system  and  the  terminal.   If  such  is 

the  case  jobs  are  accepted  from  that  terminal  but  A.  and  C.  are  first 

3  J 

computed.  A  given  job  will  only  get  access  to  those  files  with  appropriate 
jobs  category  (C„  c  C.)  which  require  no  higher  authority  than  the  job  has 
(which  should  be  less  than  or  equal  to  the  user  and  the  terminal).   If  the 
user  creates  a  new  file,  new  A„  and  C  are  assigned  according  to  the 
hisotry  concept;  clearly,  the  new  file  could  have  at  most  the  same 
authority  and  category  as  the  job  has. 

The  actual  implementation  is  very  similar  to  the  above  explanation, 
but  it  has  many  interesting  extensions  which  we  will  now  describe  briefly. 

Authority  and  category  are  implemented,  basically  as  defined. 
F  is  only  an  entry  in  the  user  dictionary  U.   Since  the  tables  are 
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organized  by  user,  instead  of  having  a  list  of  users  for  each  terminal,  F,  , 
ADEPT  has  a  list  of  terminals  for  each  user.   F.  is  simplified  to  the 
user  that  ordered  the  job.   F„  is  implemented  in  a  more  extensive  fashion, 
F-  =  ( (u,,,  q  ),  ...  (u  ,  q  )},  that  means  as  a  set  of  pairs  user-quality 
of  access,  where  the  quality  of  access  could  be:   read,  read  and  write, 
write  or  read  and  write  with  lockout  override.   If  the  file  is  public  or 
private  (all  or  only  one  user),  it  is  indicated  in  the  control  data  for 
that  file;  otherwise  (the  case  of  a  semi-private  file)  the  actual  set  of 
pairs  is  kept  for  run-time  verification. 

All  tables  are  initialized  by  a  SYSIDG  program,  which  will  include 
for  each  user  who  may  be  granted  access  to  the  file:  up  to  6*4-  use-only-once 
passwords,  categories  of  terminals,  terminals  for  that  user,  authority  of 
that  user,  etc. 

At  run-time  all  files  must  be  opened,  giving  the  opportunity  for 
the  file's  franchise  to  be  verified.  New  files  must  be  cataloged  in  such 
a  way  that  the  new  authority  and  category  for  that  file  can  be  assigned 
(using  the  history  concept). 

The  ADEPT  system  also  uses  hardware  assistance  to  attain  its 
objectives.  A  number  of  machine  instructions  are  "privileged"  to  the 
supervisor  state  only.   Instructions  that  change  the  machine  state  and 
those  dealing  with  input/ output  are  privileged.   Main  memory  is  selectively 
protected  against  unauthorized  change  (write  protected).   The  ADEPT'S  360/50 
was  also  modified  to  include  fetch  protection,  which  guards  against 
unauthorized  reading  of  (or  executing  from)  protected  memory.   The  memory 
protect  instructions  are  also  privileged.   All  security-vulnerable 


20 

functions  including  hardware  errors,,  external  timer  and  keyboard  actions, 
user  program  service  request,  illegal  instructions,  memory  protect 
violations,  and  input/ output  are  called  to  the  attention  of  ADEPT  by  the 
system/360  interrupt  system.   The  burden  for  security  integrity  is  then 
one  for  ADEPT  software. 

The  ADEPT-50  system  provides  an  interpreter  for  dynamic  debugging 
which  checks  all  requests  for  legality  based  on  range  checks  on  the  data 
addresses. 

Input/ output  is  handled  by  two  subroutines  of  the  system.   The 
first  is  a  special- purpose  compiler  whose  output  references  the  second 
subroutine — an  I/O  supervisor.   Legality  checks  are  always  performed- -this 
includes  examination  of  device  address,  machine  state  of  calling  program, 
location  of  specified  buffer  areas,  etc. 

The  problem  of  classified  residues  is  also  taken  into  consideration. 
Core  pages  (main  core  and  drum)  are  always  cleared  to  zeros  before 
assignment,  and  always  full  pages  are  swapped.   Disk  files  are  kept  as 
"dirty"  memory  due  to  the  expense  of  erasing  all  of  it,  but  the  system 
always  assumes  that  an  end  of  file  (EOF)  exists  immediately  after  the 
last  record  written  in  a  file,  and  prohibits  reading  beyond  that  EOF. 
Contaminated  tracks  allocated  to  new  files  cannot  be  read  until  they  are 
first  written. 

The  two  highest  authorities  are  reserved  for  system  files  and 
the  highest  of  all  is  for  the  SYSLOG  file  only.   Access  to  these  files 
are  restricted  to  the  system  only,  and  special  access  checks  are  made: 
First  a  special  user  code  (not  in  U)  is  required.   Second  the  programs 
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making  the  OPEN  must  "be  in  supervisor  mode,  and  third,  the  program  making 
the  OPEN  must  be  a  member  of  a  short  list  maintained  by  the  supervisor. 

Finally,  ADEPT  also  provides  a  variety  of  service  commands  that 
involve  security  control,  including  AUDIT  (for  security  audit  recording), 
CREATE  (to  establish  users  and  access  rights  for  semi-private  files),  etc. 

As  an  indication  of  performance,  Weissman  says  that  the  ADEPT'S 
overhead  CPU  cost  is  estimated  to  be  one  or  two  percent  of  total  CPU  time 
for  normal  operation,  and  that  the  overhead  in  checking  I/O  channel 
programs  is  between  5  and  10  msec  per  call. 

E.   Protection  in  an  Information  Processing  Utility 

This  paper  [13]  is  a  description  of  the  security  measures  existing  in 
MIT's  MULTICS  system,  a  primary  goal  of  that  system  being  to  provide  a 
number  of  different  users  with  flexible,  but  controlled,  access  to  shared 
data  and  procedures. 

The  MULTICS  approach  is  strongly  based  on  hardware  assistance, 
and  again,  it  is  a  straightforward  implementation  of  a  simple  model. 

The  key  component  of  the  model  is  the  segment,  a  contiguous  block 
of  words  whose  length  may  vary  during  the  execution  of  a  process.   The 
segment  is  the  logical  unit  of  information  of  concern  to  the  user.  All 
addressing  is  done  by  using  an  ordered  pair  of  integers  (S,  w)  by  first 
using  the  descriptor  base  register  and  S  to  find  the  appropriate  segment 
descriptor,  which  will  contain  the  current  location  in  memory  which, 
together  with  w,  will  guide  us  to  the  proper  place. 

So  far  we  have  not  said  anything  about  security,  but  it  is  easily 
introduced  using  the  concept  of  rings.   Rings  are  an  ordered  set  of 
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classes  numbered  from  0  to  some  maximum.  An  inner  ring  i  (i  >  0)  has  more 
authority  than  an  outer  ring  i+j  (j  >  l).   Loosely  speaking,  a  segment 
running  in  ring  i  can  access  all  segments  in  outer  rings,  but  has,  at  most, 
very  restricted  access  to  segments  in  inner  rings  as  explained  later. 

Making  the  rings  disjoint,  i.e.,  no  program  can  cross  a  ring 
boundary,  and  assigning  each  segment  to  a  unique  ring  is  sufficient  to 
solve  the  problem  of  disjoint  and  non- communicating  programs,  but  is  not 
sufficient  to  solve  the  problem  of  sharing  segments.   That  is  why  more 
than  one  ring  number  is  attached  to  each  segment,  as  described  later. 

As  we  mentioned  above,  each  segment  will  have  a  descriptor;  each 
descriptor  will  contain  information  about  initial  absolute  address  of  the 
segment,  length,  access  indicator  and.  ring  numbers  (or  ring  bracket). 
The  access  indicator  will  specify  whether  the  segment  may  be  accessed  in 
slave  mode,  written  or  executed.   If  the  segment  is  a  procedure  (execute 
bit  on)  it  will  indicate  if  it  should  be  executed  in  master  or  slave  mode. 
Finally,  it  includes  a  fault  bit  which,  when  nonzero,  causes  a  fault  on 
any  attempt  to  reference  the  segment,  even  when  in  master  mode. 

The  execution  of  a  program  implies  the  execution  of  one  or  more 
code  segments.  Associated  with  each  program  there  exists  a  location 
counter,  which  contains  current  ring  number,  current  segment  number 
(of  segment  being  executed)  and  current  word  number  (within  that  segment). 

Each  segment  has  an  ordered.  3-vector  (n  ,  n„,  n  )  called  a  ring 
bracket  where  n  <  ru  <  n_.   Basically  a  segment  must  always  execute 
between  rings  n  and  np,  and  may  not  be  called  by  any  program  outside 
of  n  ,  i.e.,  a  program  running  in  a  ring  number  bigger  than  n  ,  as 
indicated  by  the  program's  location  counter.   Thus: 
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1.  If  the  segment  is  called  from  inside  n  it  runs 
at  level  n, . 

2.  If  called  from  between  n_  and  n  it  runs  at 


the  caller's  level. 


3.   If  called  from  between  np  and  n  it  runs 


at 


level  np.   In  this  case,  a  program  called  the 

gatekeeper  is  used  to  verify  that  the  call  goes 

to  one  of  the  legal  entry  points  to  this 

segment. 
k.     Access  from  outside  n  is  denied. 

In  cases  1  and  3  the  current  ring  number,  in  the  location  counter, 
of  the  program  is  changed  to  n  or  np.   Not  doing  so  in  case  1  would 
permit  the  called  procedure  to  break  the  ring  barrier,  since  it  would  be 
running  with  a  lower  ring  number  than  authorized.   Failing  to  change  the 
program's  ring  number  in  case  3  would  probably  make  it  impossible  for  the 
called  segment  to  accomplish  its  work  due  to  lack  of  authority.   The 
MULTICS  policy  is  to  change  the  current  ring  number  as  little  as  possible, 
i.e.,  by  the  smallest  margin. 

In  summary,  in  case  2  no  modification  in  status  is  needed.   In 
all  other  cases  an  interrupt  occurs.   If  it  turns  out  to  be  case  1,  only 
same  information  is  kept  in  a  running  stack  for  the  return  moment,  and 
the  current  ring  number  is  changed  to  n, .   If  it  happens  to  be  case  3  or 
k,    then  the  special  monitor,  the  gatekeeper,  is  called  to  verify  if  the 
intended  entry  is  one  of  the  valid  points,  or  gates,  and  as  a  result  either 
acting  as  in  case  1  (honoring  the  call  but  changing  the  current  ring 
number  by  a  minimal  margin,  i.e.,  to  n0 )  or  denying  the  access  (case  k) . 
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Data  segments  have  a  different  interpretation.   If  our  program  is 
running  in  ring  i  we  can  read,  and  write  data  in  segments  with  i  <  n  , 
only  read  if  n  <  i  <  n  and  no  access  is  granted  if  i  >  ru. 

In  the  MULTICS  system  all  programs  and  files  are  kept  as  segments 
in  disk  memory  when  inactive,  so  the  ring  mechanism  provides  file  security 
and  access  control  verification  and  enforcement. 

Just  one  question  remains.   How  should  arguments  be  passed?   If 
we  change  the  ring  number  we  could  get  into  a  situation  where  the  arguments 
are  inaccessible  for  the  callee.   This  imposes  the  necessity  of  copying 
the  arguments  which  is  what  MULTICS  does. 
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III.   COMMEJNTS 

A.  Multi-dimensional  Security  Program  for  a  Generalized 
Information  Retrieval  System 

The  idea  of  a  multi-dimensional  security  program  for  a  generalized 
information  retrieval  system  (GIRS)  [8]  is  a  very  valuable  approach  to  solving 
security  problems  within  data-banks,  but  not  within  a  complete  and 
multi-purpose  system. 

We  obtain  some  security  only  if  we  work  within  the  GIRS  system, 
but  the  security  of  the  GIRS  system  itself  is  undefined. 

I  must  say  that  I  do  not  like  the  implementation  made  by  Carroll, 
et  al.   It  simply  is  too  restrictive  in  many  directions  and  I  can't  find 
a  justification  for  such  restrictions—the  answer  could  probably  lie  in 
the  PDP-10  system  which  I  do  not  know. 

First  of  all,  I  do  not  understand  why  they  restrict  themselves 
"to  99>998  records.   The  only  places  where  they  use  such  a  figure  is  in 
the  determination  of  the  7-digit  line  number,  in  the  index  table  (to  data 
records)  contained  in  the  header,  and  explicitly  in  each  line. 

I  do  not  understand  why  the  index  table  (to  data  records)  is 
needed  at  all,  given  that  all  records  have  the  same  number  of  items,  that  all 
items  have  the  same  number  of  lines  (this  is  not  mentioned  but  I  infer  it 
because  the  number  of  lines  per  item  is  given  once  in  the  header)  and  that 
no  garbage  collection  is  done  on  deleted  records.   Therefore,  a  very  simple 
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way  of  computing  the  FORTRAN  record  number  could  be  used  instead.   If  such 
an  idea  is  followed,  the  space  used  within  each  line  to  store  the  record- 
number,  item-number  and  line-number  is  unnecessary  and  could  be  removed 
from  the  data  base. 

The  GIRS  system  seems  to  be  very  batch  oriented,  with  commands 
that  will,  in  general,  refer  to  the  entire  data  base;  thus,  a  SEARCH  command 
will  probably  imply  a  search  of  the  full  data  base. 

The  optional  feature  for  locking  records  is  something  very  difficult 
to  use  and  probably  useless.   The  idea  of  modulo- remainder  is  silly. 
Imagine  yourself  trying  to  find  an  appropriate  place  for  a  new  register 
that  should  be  seen  by  many  but  not  all  users.   If  the  data  base  is  rather 
full  and  each  user  has  another  modulo- remainder  pair,  the  work  could  be 
prohibitively  large,  and  we  would  need  a  computer  to  solve  it! 

It  seems  to  me  that  the  GIRS  system  is  somewhat  expensive,  from 
the  point  of  view  of  storage.   Having  information  only  in  multiples  of 
72  characters  (with  8  additional  for  other  purposes)  can  be  very  wasteful, 
especially  if  some  items  are  variable  length,  e.g.,  if  one  item  usually 
requires  5  characters  but  sometimes  requires  100  we  would  always  have  to 
allocate  160  bytes. 

The  paper  is  also  a  little  incomplete,  for  example,  no  explanation 
about  how  elements  are  searched  or  stored  is  given. 

My  conclusion  is  then  that  even  though  Carroll  et  al.  have  a  good 
approach  to  obtain  security  within  a  data-base  (and  using  only  one  access 
program),  their  implementation  is  rather  poor  and  lacks  many  ideas  of 
dynamic  storage  and  retrieval  commonly  used  in  current  systems. 
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B.  The  Formulary  Model  for  Flexible  Privacy  and 
Access  Controls 

As  the  author  mentions  [15]  >  since  he  does  not  consider  in  his  model 
problems  associated  with  operating  system  software  bugs,  administrative 
procedures,  personnel,  etc.,  it  does  not  approach  a  comprehensive  system. 

I  must  join  Conway,  et  al.  [10]  in  their  concern  about  the  implciit 
overhead  not  mentioned  by  the  author.   The  invocation  of  all  the  procedures 
involved  imply  a  run-time  overhead  that  is  very  costly  for  situations 
where  data- dependent  security  is  not  required.   This  is  probably  an 
important  reason  which  prevented  (by  April  1972)  the  full  implementation  of 
the  model  for  the  Student  Health  System,  since  the  partial  implementation  is 
able  only  to  grant/deny  read-only  or  read/write  access  to  the  entire  file. 

Hoffman's  paper  seems  to  be  the  first  one  to  consider  data- dependent 
security  and  it  therefore  deserves  an  important  place  in  the  history 
of  security. 

In  summary,  the  basic  limitations  of  this  method  as  a  comprehensive 
system  relate  to  the  author's  decision  to  refer  only  to  data-base  security, 
and  his  neglect  to  estimate  the  implicit  overhead  caused  by  complete 
run-time  checking. 

For  a  given  data-base,  this  system  furnishes  security  provided  all 
references  to  the  data-base  are  through  legal  calls  to  the  author's 
software . 

C.  On  the  Implementation  of  Security  Measures  in 
Information  Systems 

I  must  confess  that  I  like  this  paper  [10]  very  much  and  I  agree  with 

the  vast  majority  of  the  ideas  that  are  brought  up. 
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The  idea  of  translation  time  checking  is  great  and  seems  to  me  to 
be  a  very  good  solution. 

The  only  comments  that  I  can  make  refer  to  the  general  implementation 
of  their  ideas. 

As  the  authors  point  out,  their  model  could  only  be  secure  if 
contained  within  a  secure  environment.   My  feeling  is  that  they  do  not 
arrive  at  a  comprehensive  system  at  any  moment  and  that  the  possible 
problems  to  be  solved  before  one  gets  a  secure  system,  listed  in 
section  7^  is  rather  short  and  incomplete.   Let's  take  the  Burroughs  67OO 
as  an  example.   The  E67OO  is  a  segment  oriented  machine  (no  pages 
involved).   Thus,  each  array,  for  example,  is  allocated  as  the  exact 
number  of  words  required  by  the  system.   This  forced  the  B67OO  designers 
to  put  much  more  care  in  the  detection  of  illegal  addressing,  since,  in 
general,  other  programs  could  be  affected  by  this  type  of  error.   The 
solution  was  then  a  very  strict  hardware  verification  of  index  bounds, 
impossible  to  break.   On  the  other  hand,  absolute  addresses  are  never 
handled  by  a  user,  and  pointers  refer  only  to  locations  relative  to  an 
array. 

By  the  above  discussion  it  would  seem  that  the  B67OO  is  an  optimal 
host  for  the  proposed  model,  since  none  of  the  "serious  remaining  problems" 
exist.   In  reality  this  is  not  the  case  and  the  B67OO  is  actually  an 
insecure  system.   The  operating  system  (MCP)  could  easily  be  fooled  by 
a  specially  made  tape.   The  use  of  the  DCALGOL  or  ESPOL  compilers  by  users 
could  overcome  any  security  measure,  etc. 
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What  I  am  trying  to  say  is  that  Conway,  et  al. 's  approach  is 
really  a  good  one,  but  still  far  from  comprehensive.   I  must,  however, 
agree  that  it  is  a  proper  initial  step  and  a  big  one. 

A  second  comment  is  about  the  complete  lack  of  hardware  considera- 
tions in  the  general  implementation.   Clearly,  the  combination  of  hardware 
and  software  will  give  a  much  stronger  basis  for  solving,  in  an  economic 
way,  the  "serious  remaining  problems. " 

Finally,  I  will  just  make  a  brief  comment  about  the  idea  of 
introducing  some  security  measures  into  the  standard  compilers.   My  feeling 
is  that  some  security  measures  are  really  "correctness  measures"  and 
should  in  any  case  be  incorporated  in  standard  compilers,  at  least  for 
pedagogical  reasons.   New  students  will  generally  make  involuntary  mistakes 
when  they  produce  an  invalid  index  rather  than  use  it  as  a  tricky  way 
for  some  strange  requirement  and  my  question  is:   Should  we  detect  such 
errors  and  notify  the  user? 

JD.   Security  Controls  in  the  ADEPT-50  Time- sharing  System 

The  ADEPT-50  [24]  seems  to  be  one  of  the  best  approaches  for  comprehen- 
sive security  if  we  accept  the  restrictions  imposed  by  current  commercial 
equipment.   However,  it  is  still  far  from  being  comprehensive. 

As  is  easily  seen,  the  ADEPT-50  lacks  any  type  of  security  below 
the  file  level,  i.e.,  no  protection  against  the  "Trojan  horse"  problem 
is  given,  and  there  exists  either  total  or  no  access  to  all  information. 
Clearly,  no  data-dependent  or  even  time-dependent  access  to  files  is 
given,  and  granting  access  means  granting  access  to  the  full  data-base 
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which  violates  the  need-to-know  property  so  strongly  recommended  by  the 
author  (unless  data  duplication  is  used  in  such  cases). 

My  feeling  about  the  overhead  I/O  figure,  5  to  10  msec  per  call, 
is  that  it  is  intolerably  high.   For  a  standard  industrial  moving  head 
disk,  assuming  no  seek  time  (sequential  read),  an  average  access  is  the 
order  of  12.5  msec  per  read,  which  means  that  we  would  have  as  much  as 
kO   to  80  percent  overhead,  if  used  in  ADEPT.   This  figure  is  only 
acceptable  if  we  start  with  a  military  system  that  runs  in  a  sequential 
one -program- only  fashion.   Some  further  work  in  the  hardware  area  and 
in  the  secure-translator  field  (Conway,  et  al.  [10])  would  probably  assist 
in  looking  for  a  better  solution. 

From  the  administrative  viewpoint,  the  ADEPT-50  relies  very  much 
on  the  system  programmer's  loyality.   Giving  the  system  programmer  an 
authority  over  all  other  user  authorities  is  risky  and  would  be  unacceptable 
to  many  security  administrators. 

In  summary,  this  paper  describes  a  very  good  approach  to  security 
within  the  actual  commercial  and  military  environments,  but  it  also  seems 
very  rigid  and  closed  to  new  ideas  (such  as  interprogram  communication). 
The  I/O  overhead  figures  leave  something  to  be  desired  and  security 
below  the  level  of  files  is  missing. 

E.   Protection  in  an  Information  Processing  Utility 

Graham's  paper  [13]  describes  a  very  good  approach  to  comprehensive 
security,  with  very  strong  interaction  between  software  and  hardware  for 
that  purpose.   The  ideas  are  simple  and  seem  to  work  nicely  in  the 
environment  described.   But,  once  more,  it  is  not  as  yet  a  comprehensive 
system. 
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No  provision  exists  in  MULTICS  for  protection  lower  than,  the  file 
level.   The  "Trojan  horse"  problem  remains  as  alive  here  as  in  the 
ADEPT-50,  with  an  all-or-none  authorization  schema  for  file  accesses. 

Graham's  article  is  a  little  incomplete  in  the  sense  that  no  word 

is  mentioned  about  user  codes  or  passwords  to  the  system  or  segments,  nor 

about  handling  memory  residues.   If  we  go  by  what  is  said  there,  assigning 

a  ring  bracket  to  a  procedure  is  rather  a  difficult  decision.  We  are 

trying  to  map  the  security  hierarchy  into  a  single  line  and  this  may  not 

always  be  possible.   To  see  this,  let's  suppose  that  we  have  three 

procedures  :  A,  B  and  C,  each  with  different  users  and  each  with  access 

bracket  (nL,  n2  ,  n3v)  (k  =  a,  b  or  c).   We  want  A  to  call  B  but  not  C,  B  t< 

call  C  but  not  A,  and  C  to  call  A  but  not  B.   Thus,  if  a,  b,  and  c  are  the 

ring  numbers  that  the  location  counter  will  have  when  A,  B  and  C  are 

respectively  running,  we  have : 

a  <  n3,  ,  a  >  n3   (A  can  call  B  but  not  C) 
—   b        c 

b  <  n3  ,  b  >  n3   (B  can  call  C  but  not  A) 

C  £1 

c  <  n3  ,  c  >  n3,  (C  can  call  A  but  not  B) 
a       d 

or  in  another  order: 

a  <  n3,,  n3^  <  c,  c  <  n3  ,  n3  <  b,  b  <  n3  ,  n3  <  a 

D      D  B.      3,  C      C 

which  implies  a  <  a  and  thus,  impossible  to  solve  with  the  described  model. 

In  one  of  the  references  in  the  paper  Corbato,  et  al.  [11] 
mentions  that  in  MULTICS  a  user  is  assigned  to  each  segment,  and  the 
user  has  the  capability  of  mentioning  other  users  that  could  use  his 
segment,  my  feeling  is  that  that  idea  should  have  been  mentioned  in 
Graham's  paper. 
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With  the  addition  of  user  code  there  will  exist  a  way  of  getting 
by  the  above  problem,  namely,  to  use  different  user  codes  for  each 
segment  and  deny  access  to  the  user  code  corresponding  to  the  segment 
which  is  to  be  denied  access. 

The  above  example  was  mentioned  to  show  that  assigning  of  a  ring 
bracket  is  not  trivial,  but,  if  handled  carefully  and  with  some  help,  will 
make  the  model  workable. 

The  inclusion  of  the  user  code  for  a  segment  is  a  must  if  the 
ring  numbers  are  going  to  be  assigned  by  the  user,  since  if  two  users 
happen  to  choose,  let's  say,  the  same  ring  bracket,  no  protection  for  one 
against  the  other  exists. 
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IV.   SUMMARY 

I  would  say  that  a  system  is  secure  when  the  access  to  any  one 
of  the  machine  resources  containing  user  information  is  controlled  by  the 
user  who  initially  stored  such  information.   No  access  should  be  granted 
to  information  if  the  proper  authorization  is  not  given;  this  includes 
main  and  secondary  memory,  either  in  active  or  inactive  (residues)  form. 

As  it  was  pointed  out  in  the  introduction,  there  does  not  exist 
a  completely  secure  system.   Instead  of  dealing  with  an  idealized  approach 
to  a  secure  system  we  should  pay  attention  to  minimizing  the 
vulnerability  to  security  hazards.   In  the  introduction  I  justified 
restricting  myself  to  security  controls  built  into  a  data  processing 
system,  assuming  that  all  other  security  types  are  not  a  matter  of 
concern- -I  further  neglect  the  occurrence  of  malfunctions.   In  summary, 
we  are  dealing  with  an  idealized  system  where  the  only  problem  is  to 
protect  the  community  of  legal  users  against  themselves,  and  we  then  try 
to  get  to  a  secure  system.   Unfortunately,  even  with  all  the  above 
assumptions,  such  a  system  does  not  yet  exist  in  a  cost-effective 
version,  with  the  military  solution  discussed  next,  being  the  only  one 
in  such  a  category. 

The  minimization  problem  should  not  be  viewed  as  a  goal  by 
itself — there  are  many  trade-offs.   One  extreme  is  to  minimize  vulnerability 
regardless  of  cost,  as  in  the  military  solution  of  a  one-program  dedicated 
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computer.   A  computer  is  assigned  to  one  program  at  a  time,  with  a  memory 
cleaning  phase  following  such  program.   The  cost  involved  is  clear: 
underutilization  of  computer  power  by  not  utilizing  multiprogram  and 
time- sharing  techniques,  waste  of  time  in  erasing  memory,  difficulties 
for  sharing,  etc . 

Another  extreme  could  be  the  current  manufacturer's  general 
approach  -do  as  little  as  possible  if  it  implies  any  throughput  degradation. 
The  cost  of  leaking  information  is  thus  neglected. 

The  cost  of  the  first  approach  is  enormous  and  the  solution 
introduces  other  problems  such  as  the  difficulty  of  sharing  hardware. 
In  the  latter  case,  the  cost,  as  viewed  from  a  throughput  analysis,  is 
practically  zero.   The  security  obtained  is  almost  non-existent. 

It  is  my  belief  and,  I  guess,  the  unstated  belief  of  the  authors 
of  the  presented  papers,  that  good  solutions  exist  between  these  two 
extremes.   A  reasonably  secure  system  should  clearly  satisfy  the  user's 
security  needs,  but  efficiency  should  not  be  sacrificed  by  imposing 
unacceptable  additional  costs  as  the  military  approach  does. 

Identifying  the  user's  security  needs  is  not  a  simple  task--we 
should  start  by  defining  what  do  we  mean  by  "user. "  In  the  following 
discussion  we  will  simply  identify  the  word  "user"  with  the  community  of 
users  of  a  multipurpose  computer. 

The  needs  of  a  community  of  users  are  certainly  of  a  diverse 
nature;  some  users  wish  to  share  data  and  procedures.   Some  others,  like 
commercial  competitors,  would  require  to  be  protected  against  each  other. 
A  third  group,  for  example,  software  producing  companies,  will  have 
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programs  that  they  want  to  rent.   In  summary,  a  community  of  users  needs 
a  flexible  but  controlled,  access  to  shared  information. 

Now  we  can  expand  a  little  more  the  concept  of  a  reasonable  secure 
system.   It  should  first  of  all  satisfy  the  requirements  established  at 
the  beginning  of  this  section  to  be  called  secure.   It  should  try  to 
take  advantage  of  existing  computer  power  (such  as  multiprogramming)  and 
should  finally  permit  users  to  share  information  by  imposing  selective 
security.   Cost-effectiveness  should  be  used  to  compare  such  systems 
and  even  to  establish  their  feasibility. 

The  selective  security  should  be  contemplated  from  various  levels, 
starting  with  the  selection  of  users  allowed  on  the  system,  to  the 
terminals,  then  to  programs  and  files,  to  records  within  a  file,  and 
finally,  to  fields  within  a  record  (the  last  two  are  called  protection 

I   levels  three  and  two  respectively  by  Carroll,  et  al.  [8]). 
The  vital  question  arises:  How?  ...   How  do  we  go  about 
implementing  such  a  reasonably  secure  system? 

The  described  papers  are  an  incomplete  answer  to  this  question. 
A  real  life  implementation  of  a  security  system  is  extremely 
dependent  on  the  actual  machine  that  we  are  dealing  with,  but  some  kind 
of  generalization  or  compromise  must  be  made  for  the  purpose  of  this 
paper.   We  then  impose  the  Utopian  goal  of  "as  machine  independent  as 
possible"  for  the  following  discussion.  By  so  doing  we  can  concentrate 
on  underlying  principles  and  avoid  endless  debates  on  the  relative  merits 
of  different  vendor  hardware. 

The  first  property  of  a  secure  system  should  be  to  be  able  to 
protect  users  from  each  other;  more  specifically,  the  initial  concern 
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should  be  to  protect  the  operating  system  from  any  other  user.  Any 
information  inside  a  computer  is  managed  and  moved  around  by  the  operating 
system.  Not  making  the  proper  distinction  between  operating  system  and 
other  programs  threatens  not  only  the  security  but  the  complete  operation 
of  a  computer.   This  fact  is  widely  accepted,  and  a  common  solution  is 
to  have  two  system  states:  master  and  slave.   The  computer  is  in  the  first 
one  when  operating  system's  code  is  being  executed  and  in  the  second  one 
if  such  is  not  the  case.   Furthermore,  some  instructions  could  be  ■ 
protected  instructions,  meaning  that  they  could  only  be  executed  in  the 
master  state. 

One  common  way  to  break  security  is  to  make  the  operating  system 
fool  itself  by  either  writing  into  space  allocated  for  its  code  or  making 
it  execute  code  created  by  the  user  in  one  of  his  data  areas.   A  way  of 
protecting  against  this  danger  is  mentioned  in  Graham's  paper  [13]  for 
the  MULTICS  system,  where  various  protection  bits  are  assigned  to  each 
segment  and  verified  by  the  hardware  each  time  that  a  segment  is  accessed. 
Each  segment  contains  an  "access  indicator"  which  specifies  whether  the 
segment  may  be  accessed  in  slave  mode,  written  or  executed.   Further,  if 
the  segment  is  a  procedure  it  specifies  whether  the  procedure  is  to 
execute  in  master  mode  rather  than  in  slave  mode.   Finally,  it  includes 
a  fault  bit  which  when  nonzero,  causes  a  fault  (or  trap  or  interrupt)  on 
any  attempt  to  reference  the  segment,  even  when  in  master  mode. 

In  order  to  protect  the  operating  system  as  well  as  concurrent 
users  from  each  other,  a  user  should  not  be  able  to  break  the  barrier  of 
his  own  environment.   His  code  should  allow  him  access  only  to  his  own 
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data  (read/write)  and  procedures  (read  only)  (own  in  the  above  context 
means  that  he  is  making  legitimate  use  of  it  and  it  could  mean  the 
legitimate  shared  use  of  somebody  else's  data  or  procedures).   Invalid 
index  checking  should  be  included.  A  few  alternative  solutions  are 
available :  using  a  preprocessor  to  check  legality  at  compile  time, 
generating  additional  code  (and  overhead)  to  verify  legality  at  run-time 
(both  of  them  mentioned  by  Conway,  et  al.  [10]),  or  to  rely  on  a  hardware 
verification,  as  the  MULTICS  and  the  B67OO  machines  do. 

If  the  operating  system  is  able  to  protect  itself,  then  many  other 
secondary  benefits  are  gained,  as  for  example,  a  controlled  access  to 
files  is  almost  automatically  obtained,  since  all  information  needed  to 
deny  or  grant  access  to  those  files  could  be  thought  of  as  data  of  the 
operating  system.   We  should  then  put  special  emphasis  on  safeguarding 
the  operating  system.   All  possible  dangers  should  be  studied  in  systems 
where  there  exist  a  super  powerful  language  especially  made  for  the 
operating  system  (ESPOL  for  the  B67OO).   Its  use  should  either  be 
forbidden  or  carefully  monitored.   Simple  threatening  hazards  such  as 
the  acceptance  of  tapes  or  disk-packs  containing  code  generated  elsewhere 
should  not  be  overlooked,  and  should  either  be  forbidden  or  very  carefully 
checked. 

Sharing  of  procedures  should  be  enforced,  but  in  a  well  defined 
way,  MULTICS ' s gatekeeping  idea  seems  reasonable  [13].   Clearly,  parameter 
verification  should  be  performed,  especially  when  they  are  specified  by 
absolute  addresses. 

Data  sharing  should  also  be  available;  this  requirement  emphasizes 
the  need  for  some  multiaccess  control- -many  users  could  be  attempting 
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to  access  and  modify  the  same  records  simultaneously.   Hoffman's  paper  [15] 
gives  one  of  the  possible  solutions,  namely,  to  add  such  operations  as 
STORELOCK,  FETCHLOCK,  LOCKLIST,  etc.  as  an  integral  part  of  the  system. 
Next,  we  should  take  care  of  inactive  information,  also  known  as  residues. 
Weissman's  discussion  [2h]    seemed  to  be  fairly  complete,  and  adopting 
the  proposed  ideas  would  give  us  the  desired  protection. 

Finally,  we  get  to  the  point  where  protection  types  2  and  3  (as  in 
Carroll,  et  al.  [8]),  i.e.,  from  file  down,  must  be  taken  care  of.  . 
Interestingly,  the  discussed  papers  seem  to  obey  some  strange  dichotomy 
rule :   either  they  attack  the  security  problem  from  the  file  level  up 
or  else  from  the  file  level  down,  but  never  both.   Conway,  et  al.  [10] 
is  the  only  one  who  speaks  in  a  broad,  incomplete  and  quick  fashion  of 
the  necessity  of  dealing  with  the  other  half  of  the  problem — in  his  case, 
protection  from  the  file  level  up. 

If  we  follow  the  -guidelines  of  the  papers  studied,  we  could 
approach  a  comprehensive  system  in  two  ways:   a)  from  the  top  down,  by 
building  the  file  level  down  protection  into  one  of  the  available 
systems:  ADEPT-50,  MULTICS,  etc.  or  b)  from  the  bottom  up,  which  would 
require  constructing  reliable  environment  for  a  file  level  down  working 
subsystem.   The  latter  attack  is  followed  and  discussed  by  Conway,  et  al.  [10] 

From  the  available  information,  it  now  seems  logical  to  me  to 
suppose  that  some  merging  between  a  file-up  and  file-down  subsystem  could 
lead  to  a  comprehensive  secure  system,  as  for  example,  the  combination  of 
Graham's  (MULTICS  [13])  and  Conway,  et  al. 's  [10]  systems.  Unfortunately, 
there  are  many  omissions  in  the  literature,  and  the  above  conclusion  could 
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be  false  (for  example,  none  of  them  mentions  the  word  residues  or  inactive 
information). 

A  few  words  about  a  cost-effective  analysis  are  needed.   Even 
though  the  above  combination  could  lead  us  to  a  comprehensive  secure  system, 
it  will  probably  not  correspond  to  the  most  cost-effective  solution. 
MULTICS  is  a  fairly  expensive  system,  and  probably  unfeasible  for  many 
existing  systems  with  security  needs.  My  feeling  is  that  the  next  step 
should  be  a  deeper  study  of  the  concepts  discussed  here,  with,  probably,  a 
more  specific  system  in  mind,  which  could  lead  to  a  well-defined  project 
and  perhaps  an  actual  implementation  of  a  comprehensive  security  system. 
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